Loading an application to be deployed in a terminal and chip a card

ABSTRACT

In order to rapidly load from a server ( 1 ) an application to be deployed (AP) in a terminal ( 2 ) and a chip card ( 3 ), a message (MAP) containing both a first application part and second application part formatted so as to be compatible with a protocol for communication between the terminal and the card is transmitted by the server to the terminal, which stores the two parts. The first part (APT) extracted from the application message (MAP) is installed in the terminal. A specific loader (CAPC) loads the second part (APC) extracted from the message according to the communication protocol. The installations of the two application parts are thus synchronous under the control of the terminal.

The present invention concerns the loading of an application to bedeployed, also referred to as an application to be distributed, in aterminal and a chip card, also referred to as a microcontroller card orintegrated-circuit card.

The terminal accepts the chip card and can, according to a preferredexample, be a mobile radiotelephone terminal for which the chip card isa removable user identity module SIM (Subscriber Identity Module), towhich reference will be made later in the description. In otherexamples, the terminal can be a bank terminal accepting a debit orcredit card, or a personal computer (PC) provided with a chip cardreader, or small communicating equipment such as a personal digitalassistant (PDA) able to read a chip card introduced into it.

The invention thus concerns in general terms an open terminal in whichthere is implemented an open operating system which allows dynamicdownloading of additional applications “on top of” the operating systempartially in a chip card accepted in the terminal.

Referring to FIG. 1, this depicts the main entities for downloading anapplication composed of a first part PA1 and a second part PA2 from anOTA (Over The Air) platform such as an application server SAP to amobile radiotelephone TE containing a removable chip card CP of the SIMcard type. The terminal TE and the chip card CP each contain aninterpreter of the Java or Microsoft (registered trade marks) virtualmachine type. In particular, the terminal includes a card manager G formanaging the data exchanges between the world external to the terminalTE and the chip card CP.

The application server SAP is managed for example by an applicationprovider for mobile terminals and operates in the following manner inorder to download an application composed of the parts PA1 and PA2.

The first part PA1, intended to be loaded into the terminal TE, isdownloaded through a network of packets of the Internet type RP, aswitched telephone network RTC and the radiotelephone network RR towhich the terminal TE belongs. The downloading of the first applicationpart PA1 is carried out at a higher rate, typically 9600 bits/second, inparticular through a traffic channel of the radiotelephone network RR.The part PA 1 is installed and managed by an application manager Gimplemented in the terminal.

The second application part PA2, intended for the chip card CP, can bedownloaded only be means of short messages MC whose transmission rate islow, a few hundred of bits per second, and therefore very much less thanthe rate for downloading the first application part PA1. Thus the secondapplication part PA2 passes through the packet network RP, a shortmessage server SMC generally generating several short messages MCsegmenting the application part PA2 transmitted directly or through anintermediate network RI of the ISDN or X.25 type to the radiotelephonenetwork RR, and then through the terminal TE, which is transparent tothe application part PA2.

The separation of the application into two parts PA1 and PA2 through thedifferent transmission parts RP-RTC-RR and RP-SMC-RI-RR naturally givesrise to a desynchronisation of the application parts actually downloadedseparately into the terminal TE and the chip card CP. Since thedownloadings are performed separately, the terminal TE and the chip cardCP acknowledge reception of the downloading of the parts PA1 and PA2 tothe server SAP separately rather than simultaneously before commencingany execution of the application [PA1, PA2] in the terminal TE and chipcard CP assembly. In particular, the application manager G must waituntil the second application part PA2 is completely downloaded into thecard CP at the said low rate in order to decide on execution of theapplication.

The main objective of the invention is to remedy the drawbacks due tothe desynchronisation of the downloading of the two application partsaccording to the prior art. It aims more particular to provide asynchronisation mechanism for the terminals so that it itself loads thesecond part of the distributed application whilst having rapidlyreceived the two parts of the application at an appreciably higher ratethan that offered by a short-message transmission. If necessary theterminal transmits only one acknowledgement message after theinstallation of the application in the terminal and chip card.

In order to achieve this objective, a method for loading from a serveran application including a first part intended for a terminal providedwith an application management means and a second part intended for achip card accepted in the terminal, is characterised in that itcomprises the steps of:

supplying to the terminal a loading means for loading the secondapplication part in the chip card,

formatting in the server the second application part so that it iscompatible with a protocol for communication between the terminal andthe chip card,

constructing in the server an application message containing the firstapplication part and the second formatted application part,

transmitting the application message from the server to the terminalsover a single transmission channel,

installing in the terminal the first application part extracted from theapplication message via the management means, and

loading the second application part extracted from the applicationmessage from the terminal into the chip card according to thepredetermined communication protocol under the control of the loadingmeans.

The invention thus dispenses with the problem of desynchronisation ofthe loadings of the first and second parts of the application since bothare installed respectively in the terminal and chip card under thecontrol of the application management means and of the loading meansimplemented in the terminal. No additional means for managing thesimultaneous transmission of the two application parts in an commonapplication message is necessary in the server. A single acknowledgementcan be transmitted by the terminal to the server in order to indicatethe availability of the application installed in the terminal for beingexecuted.

The management means analyses a descriptor of the application which hasat least one identifier of the second formatted application part andwhich is contained in the application message constructed in the server.The management means then analyses the descriptor in the applicationmessage received by the terminal so that the second application part isextracted from the application message according to the identifier inthe descriptor analysed. The charging means is then activated by themanagement means in order to load the second application part in thecard. The terminal thus itself manages the loading of the secondapplication part in the card in synchronism with the installation of thefirst application part in the terminal.

The downloading of the application to the terminal uses according to theinvention an existing transmission path whatever the type of terminal,which may be a mobile radiotelephone terminal, a personal computer, etc.In particular, when the terminal is a mobile radiotelephone terminal,any application is transmitted over a traffic channel on the radiointerface between the terminal and a base station of the radiotelephonynetwork, that is to say at an appreciably higher rate than by means ofshort messages according to the prior art.

Other characteristics and advantages of the present invention willemerge more clearly from a reading of the following description ofseveral preferred embodiments of the invention with reference to thecorresponding accompanying drawings, in which :

FIG. 1 is a schematic block diagram between an application server and aterminal with a chip card according to the prior art already commentedon;

FIG. 2 is a schematic block diagram of a telecommunications systembetween an application server and a terminal with a chip card accordingto the preferred embodiment of the invention in which the terminal is amobile radiotelephone terminal;

FIG. 3 is a graph showing the composition of an application messagetransmitted by the server to the terminal, according to the invention;and

FIG. 4 is an algorithm of the two-part application loading methodaccording to the invention.

The preferred embodiment of the invention described below with referenceto FIG. 3 concerns by way of example the loading of an application froman application server 1 into a terminal 2 of the mobile radiotelephoneterminal type provided with a chip card 3.

In the three entities 1, 2 and 3, there are depicted in FIG. 2functional blocks providing functions having a connection with theinvention and able to correspond to software and/or hardware modules.

The terminal 2 is included in a digital cellular radiotelephone networkRR, for example of the GSM or UMTS type. More precisely, the terminal 2is connected to the server 1 through a telecommunications networkcomprising conventionally a packet network RP such as the Internet, aswitched telephone network RTC and the radiotelephony network RR. Thechip card 3 constitutes an identity module removable from the terminal2, known by the term “SIMcard” (Subscriber Identity Module). In avariant, the chip card 3 may be a chip card additional to the SIMcard.

According to other variants, the terminal may be a personal electroniccomputer (PC), or a bank terminal or a point of sale terminal or apersonal digital assistant (PDA), or a portable message transmissiondevice, etc. In association with these various types of terminal, thechip card 3 may be a portable electronic object such as a debit orcredit card, an electronic purse, an additional chip card or any othersmall or miniature electronic device.

In general, the terminal 2 contains, as a peripheral, a reader 20 inwhich the chip card 3, with or without electrical contact, is insertedat least partially.

The application server 1 constitutes an internet site belonging forexample to the chip card editor 3 or to an editor which edits theapplications to be downloaded into chip cards.

A source program PS corresponding to an application AP, a first part APTof which, which may be empty, is to be downloaded into the terminal 2,and a second part APC of which is to be downloaded into the chip card 3,was written initially in a high-level language of the object orientedtype such as Java. As will be seen hereinafter, the terminal 2 and thechip card 3 contain respectively virtual execution means such as a Java(registered trade mark) virtual machine JVMT for executing theapplication part APT and a Java card (registered trade mark) virtualmachine JVMC for executing the application part APC. In a known manner,the source program PS is converted in a converter 11 of the server 1into an intermediate language, also referred to as pseudo-code, composedof instruction words formed by bytes referred to as bytecodes, which areready to be executed by the virtual machines JVMT and JVMC implementedin the terminal 2 and chip card 3. The compiled program PGC produced bythe converter 11 contains the first compiled application part APT andthe second compiled application part APC, which correspond to thosecontained in the source program PS and supplied by a developer of theapplication editor.

In a variant, the converter 11 is implemented outside the server 1.

Each application part APT (.class) and a APC (.cap) contains a set ofcomponents constituting files which can each correspond to an objectclass, a method, a directory, a header, a descriptor, etc.

In particular, as shown in FIG. 3, the second application part APCdedicated to the chip card 3 is segmented into commands EV1 to EVN ofthe “ENVELOPE” type, which are concatenated and which contain datarelating to the second application part APC and can be loaded directlyinto the chip card 3. The commands EV1 to EVN are compatible with aprotocol for communication between the terminal 2 and the chip card 3,typically an either-way asynchronous protocol, and are able to transferthe data from the second application part APC of the terminal 2 to thechip card 3 without the terminal 2 interpreting them. The data in thecommands EV1 to EVN can therefore be interpreted directly by the virtualmachine JVMC implemented in the chip card 3, in a similar manner to ashort message received by a terminal according to the prior art andtransmitting a command “ENVELOPE (SMS-PP DOWNLOAD)” directly to the chipcard 3.

In the server 1, a formatter 12 formats the second application part APCin a succession of “ENVELOPE” commands EV1 to EVN.

The application server 1 also comprises an application messageconstructor 13 and a loader 14. The constructor 13 constructs anapplication message MAP as shown in FIG. 3. The message MAP comprises aheader EN, an application descriptor DAP, the first application part APTand the second application part APC with the concatenated commands EV1to EVN. The descriptor DAP contains in particular an identifier IAPCindicating the position of the start of the second application part APCin the message data field MAP following on from the descriptor DAP. Theidentifier IAPC will serve to extract the second application part APCfrom the message MAP stored in the terminal 2. The descriptor DAPconstitutes a JAD (Java Application Descriptor) file and the set of data[DAP(IAPC), APT, APC] constitutes a JAR (Java Application Repository)file according to the description of the Java card virtual machine. Themessage MAP thus produced by the constructor 13 thus contains an appletto be transmitted to the terminal 2 under the control of the loader 14over the telecommunications network RT. The loader 14 adapts the messageMAP to the transport protocols such as HTTP (Hypertext TransferProtocol) and network protocol (Internet Protocol) of the packet networkRP to which the server 1 is connected.

The terminal 2, of the mobile radiotelephone type, comprisesconventionally, apart from the chip card reader 20, a processor 21,memories 22 and a radio interface 23 connected by a bus 24. The memories22 group together various memories such a read only memory, a EEPROMnon-volatile memory and a RAM memory. When the terminal is for example apersonal computer, the memories 22 comprise a hard disk. Naturally theterminal 2 comprises other peripherals at the man-machine interface withthe processor 22 such as a keypad, a graphic display, at least one knownspeaker, a microphone, etc. The interface 23 transposes in frequency,converts digitally, demodulates and decodes messages received via thefixed network in the network RR.

The memories 22 in the terminal 2 contain in particular an operatingsystem, the Java virtual machine JVMT, a browser, and various dataapplications.

In particular, in the non-volatile memory of the memories 22 of theterminal 2, an application installation manager GIA programmed in Javalanguage and executable in the terminal 2 is implemented. The managerGIA serves to install various applications in the memories 22 of theterminal 2 and to launch their executions, and in particular to installand launch the first part APT of a deployed application AP according tothe invention. The manager GIA can be included in the virtual machineJVMT.

The manager GIA distinguishes, in a received application message MAP,the first application part APT intended for the terminal 2 with respectto the second application part APC intended for the chip card 3 withoutrequiring an interpretation of the data contained in the commands EV1 toEVN by the virtual machine JVMT.

In connection with the manager GIA, a loader CAPC for loading the secondapplication part APC from the terminal into the chip card isimplemented, according to the invention, also in the form of a softwaremodule in the memories 22 of the terminal 2. The loader CAPC creates alink between the virtual machine JVMT and the manager GIA implemented inthe terminal 2 and the virtual machine JVMC and an applicationinstallation tool OI implemented in the chip card 3 through thepredetermined communication protocol having protocol data units (PDU)consisting of the commands EV1 to EVN and their responses RES1 to RESNexchanged between the terminal 2 and the chip card 3.

The chip card 3, which is a removable SIM card according to thepreferred embodiment, comprises conventionally, in integrated form, amicroprocessor 31, a non-rewritable memory 32 of the ROM type, anon-volatile memory 33 of the EEPROM type and a memory 34 of the RAMtype intended essentially to exchange data with the terminal 2 throughin an input/output port 35. The memories 32 and 33 contain the codes anddata of an operating system OSC and of the virtual machine JVMCaccording to the Java card specification. The non-volatile memory 33contains various applications and is intended to receive the secondapplication part APC contained in an application message MAP transmittedby the server 1 through the terminal 2 and downloaded by the reader 20through the port 35 and RAM memory 34. The memory 33 also contains theinstallation tool OI for installing second application part APCaccording to the invention.

Referring now to FIG. 4, the method of loading an application APcomprising a first part APT intended for the terminal 2 and a secondpart APC intended for the chip card 3 comprises essentially steps S1 toS5 executed in the server 1 and steps T1 to T8 executed principally inthe terminal 2.

It is assumed that, at an initial step E0 preceding at the least thesteps T1 to T8, the second application part loader CAPC according to theinvention has been installed in the form of a software module in thememories 22, for example from a server other than the server 1.

At step S1, a developer of the application editor managing the server 1writes the application AP in high-level source language so that itcontains two parts APT and APC in Java and Java card languagesrespectively intended for the terminal 2 and chip card 3. The converter11 converts the application AP=[APT, APC] into a compiled program PGC[API, APC] in intermediate language (pseudo-code). In a variant, stepsS1 and S2 are performed outside the server 1 and the compiled programPGC is loaded in the server.

Then steps S3, S4 and S5 are respectively performed by the formatter 12,the constructor 13 and the loader 14. At step S3, the formatter 12formats the compiled application part APT and APC so that they arerespectively compatible with the installation manager GIA in theterminal 2 and the installation tool OI in the chip card 3. Inparticular, the second application part APC is segmented into protocoldata units EV1 to EVN, as shown in FIG. 3, which are in accordance withthe protocol for communication between the terminal 2 and the chip card3 at the level of the connection between the reader 20 and theinput/output port 35. Typically, the commands EV1 to EVN included in thepart APC are formatted as short messages according to the GSM standard.At step S4, the constructor 13 adds a message header EN, an applicationdescriptor DAP containing at least the second application partidentifier IAPC and preceding the concatenated application parts APT andAPC. The message MAP thus constructed contains a file of the JAR typeincluding the fields DAP, APT and APC.

Then at step S5 the loader 14 transmits the constructed applicationmessage MAP to the terminal 2 through the telecommunications network RT,that is to say over a single transmission channel, rather thanseparately in two parts over two distinct desynchronised transmissionpaths RP-RTC-RR and RP-SMC-RI-RR according to the prior art shown inFIG. 1.

On reception of the message MAP in the terminal 2, the processor 22demands the writing of the data DAP, APT, APC contained in the messageMAP in the RAM memory of the memories 22, at step T1.

At step T2, the descriptor DAP extracted from the received message MAPand stored in the memories 22 is analysed in particular by theapplication installation manager GIA which is started up. By virtue ofthe analysis of the descriptor DAP, the application parts APT and APCare marked in the data field of the message MAP. First of all, at stepT3 the installation manager GIA via the processor 21 reads the firstapplication part APT and extracts it from the message MAP in thememories 22 in order to install it in particular in the non-volatilememory of these. The part APT thus installed can be executed by thevirtual machine JVMT after the loading of the second part APC in thechip card 3. Naturally, if the part APT is empty, step T3 is notexecuted.

The manager GIA activates the loader CAPC, which extracts the secondapplication part APC from the message MAP written in the memories 22, atstep T4, ignoring the content of the part APC and particularly thecontent of the protocol data units EV1 to EVN. The loader CAPC marks thepart APC in the message MAP by means of the identifier IAPC read in theapplication descriptor DAP analysed at step T2. The part APC wascorrectly formatted for the formatter 12 in order to be directly used inthe chip card 3.

Then the loader CAPC initiates an exchange with the chip card 3 in orderto load the second extracted application part APC from the memories 22through the reader 20 and the input/output port 35 in the RAM memory 34of the chip card 3. The second application part APC is segmented intocommands EV1 to EVN so as to load them successively into the chip card3, at step T5. For each “ENVELOPE” command EVn transmitted by the reader20, with 1≦n≦N, the processor 31 in the chip card 3 connected to theinstallation tool OI returns a respective response REPn according to thepredetermined protocol for command and response exchange between thereader 20 and the chip card 3. The response REPn is analysed by theloader CAPC. If the response REPn contains a positive acknowledgement,the loader CAPC continues the process of loading the second applicationpart APC by transmitting the following EV (n+1), and so on. In thecontrary case, the response REPn contains an error that the loader CAPCindicates to the installation manager GIA, which retransmits it in theform of an error message to the application server 1. The loading of thesecond application part as the transmission of commands EV1 to EVNprogresses is completely transparent in the terminal 2, that is to sayit gives rise to no corresponding message or waiting message display inthe terminal 2. As the commands EV1 to EVN are transmitted, theinstallation tool OI progressively installs the second application partAPC in the chip card 3 by transferring the envelopes EV1 to EVN from theRAM memory 34 to the EEPROM memory 34 at step T6.

Preferably, after reception of the last response REPN from the chip card3 to the last command EVN, the loader CAPC deletes the secondapplication part APC received with the message MAP in the memories 22 atstep T7. Then the application installation manager GIA demands in theterminal 2 the transmission of an acknowledgement message ACK to theserver 1 via the network RT as soon as the loader CAPC has finished theloading of the second application part APC in the chip card 3, that isto say after steps T5 and T6 and optionally step T7.

In a variant, instead of the second application part loader CAPC beinginstalled in advance in the form of a software module in the terminal 2by electronic means other than the application server 1, the softwaremodule including the loader CAPC is previously introduced in the messageMAP by the constructor 13 in the form of a script SC, as indicatedbetween parentheses in a field of the message MAP in FIG. 3 and at stepS4 in FIG. 4. During the step S4 of constructing the message MAP, theconstructor 13 adds the script SC after the descriptor DAP, which ismodified accordingly. At step T2, the manager GIA extracts the script SCin the application message MAP received by the terminal 2 so as toinstall the script SC in the non-volatile memory of the memories 22. Thescript SC is then initiated by the manager GIA in order in particular toextract the second application part APC and to load it in the chip card3 in steps T4 and T5.

According to another variant, the application message MAP does notcontain the script SC. A script address URL (Uniform Resource Locator)designating a location in a server that has stored the script SC isintroduced during the construction S4 of the application message MAP tobe transmitted to the terminal 2. At step T2, the manager GIA in theterminal 2 extracts the script address from the message received andstored MAP and requires from the server designated by the extractedaddress the downloading of the script SC in the memories 22 of theterminal 2. The script SC is then initiated by the manager GIA in orderin particular to extract the second application part APC and to load itin the chip card 3 at steps T4 and T5.

1. A method for loading from a server an application including a firstpart intended for a terminal provided with an application managementmeans and a second part intended for a chip card accepted in theterminal, comprising the following steps of: supplying to the terminal aloading means for loading the second application part in the chip cardformatting in the server the second application part so that it iscompatible with a protocol for communication between the terminal andthe chip card constructing in the server an application messagecontaining the first application part and the second formattedapplication part transmitting the application message from the server tothe terminal over a single transmission channel installing in theterminal the first application part extracted from the applicationmessage via the management means, and loading the second applicationpart extracted from the application message from the terminal into thechip card according to the predetermined communication protocol underthe control of the loading means.
 2. A method according to claim 1,wherein the constructed application message contains a descriptor of theapplication with at least one identifier of the second application part,and the management means analyzes the descriptor in the applicationmessage received by the terminal so that the second application part isextracted from the application message according to the identifier inthe analyzed descriptor.
 3. A method according to claim 1, wherein theloading means is installed in advance in the form of a software modulein the terminal.
 4. A method according to claim 1, comprising the stepsof introducing the loading means in the form of a script during theconstruction of the application message to be transmitted from theserver to the terminal and installing the of the loading means byextraction of the script in the application message received by theterminal before the loading of the second application part.
 5. A methodaccording to claim 1, comprising the steps of introducing of an addressof a loading script during the construction of the application messageto be transmitted from the server to the terminal, installing of theloading means by extraction of the script address in the applicationmessage received by the terminal, and a downloading of the script fromthe extracted address in the terminal before loading the secondapplication part.
 6. A method according to claim 1, further comprising,after the step of loading the second application part, the step ofdeleting the second application part in the terminal.
 7. A methodaccording to claim 1, further comprising, after the step of loading thesecond application part, the step of transmitting an acknowledgementmessage from the terminal to the server M as soon as the managementmeans has finished loading of the second application in the chip card.8. A method according to claim 1, wherein the second application part issegmented into protocol units which are in accordance with thecommunication protocol and which are loaded successively in the chipcard ( under the control of the loading means, and further including thestep of transmitting from the chip card an acknowledgement responseafter the loading of each protocol unit.
 9. A method according to claim1, wherein the first and second application parts are written inhigh-level languages and are converted into an intermediate languagethat can be interpreted respectively by virtual execution meansrespectively implemented in the terminal and the chip card.
 10. A methodaccording to claim 1, wherein the terminal is a mobile radiotelephoneterminal.